home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1676.txt < prev    next >
Text File  |  1997-04-01  |  8KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        A. Ghiselli
  8. Request for Comments: 1676                                   D. Salomoni
  9. Category: Informational                                       C. Vistoli
  10.                                                                INFN/CNAF
  11.                                                              August 1994
  12.  
  13.  
  14.                      INFN Requirements for an IPng
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Overview
  23.  
  24.    This document was submitted to the IETF IPng area in response to RFC
  25.    1550.  Publication of this document does not imply acceptance by the
  26.    IPng area of any ideas expressed within.  Comments should be
  27.    submitted to the big-internet@munnari.oz.au mailing list.
  28.  
  29. Abstract
  30.  
  31.    This white paper is sent by INFN network team, the Italian National
  32.    Institute for nuclear physics, whose network, named INFNet, is a
  33.    nationwide network founded to provide the access to existing national
  34.    and international HEP laboratory and to facilitate communications
  35.    between the researchers.  With this paper we would like to emphasize
  36.    the key points that we would to consider if charged with IPng plan.
  37.    We do not really expect to add original items to the selection, but
  38.    we think that it could be useful to submit the opinions and ideas
  39.    that come from our network experience.
  40.  
  41. 1. General Requirements
  42.  
  43.    The problems that are to be solved in IP internet are mainly three:
  44.  
  45.       1. address exhaustion
  46.  
  47.       2. flat address space
  48.  
  49.       3. routing efficiency, flexibility and capacity.
  50.  
  51.    The aim of IPng study should be to define a plan that solves all
  52.    these problems as a whole and not each of them separately.
  53.  
  54.    The general requirements that we underline for this transition are:
  55.  
  56.  
  57.  
  58. Ghiselli, Salomoni & Vistoli                                    [Page 1]
  59.  
  60. RFC 1676             INFN Requirements for an IPng           August 1994
  61.  
  62.  
  63.       - transparency to the final user: user applications should not be
  64.         influenced.
  65.  
  66.       - flexibility: Simplify the suitability to new communication
  67.         technology and to topology changes due to new services provided
  68.         or to different users needs.
  69.  
  70. 2. Application and Transport Level
  71.  
  72.    Starting from the top of the OSI model, we think that the users
  73.    applications should not be influenced by the migration plan.  It
  74.    means that the TCP (the transport layer) must maintain the same
  75.    interfaces and services to the upper layers.  Anyway, it is also
  76.    necessary to foresee the use of a different transport services. The
  77.    possibility to use different transport should be offered to the
  78.    applications.  Therefore a transport selector field is needed.
  79.  
  80. 3. Network layer: service and address
  81.  
  82.    We assume that the network layer must continue to provide the same
  83.    datagram service as IP does.  CLNS could be a solution and a reliable
  84.    starting point for the IPng.  The main advantage is that this
  85.    solution has been profitable tested and it is already available on
  86.    many systems.  It is not, of course, deployed as widely as IPv4 is,
  87.    since it is a newer technology, but it is widely configured and and
  88.    there is already operational experience.  The corresponding address,
  89.    the NSAP, is 20 bytes long.  It is long enough to scale the future
  90.    data network environment.  Its hierarchical format can be organized
  91.    in a really flexible way, satisfying hierarchical routing and policy
  92.    based routing needs and simplifying the distributed administration
  93.    and management.  A lot of work has been already done in the majority
  94.    of the countries in order to define NSAP formats satisfying both the
  95.    requirements of administrative delegation and routing performances.
  96.  
  97. 4. Routing protocols
  98.  
  99.    We don't consider the decision about the routing protocol to be
  100.    adopted for the IPng to be fundamental.  Even if this choice is very
  101.    important to obtain good performances, the routing protocols can be
  102.    changed or improved at any time, because there is no influence into
  103.    the End Systems configuration.  Relationships between NSAP
  104.    aggregation, hierarchical topology and hierarchical routing algorithm
  105.    must be taken into account in IPng plan.  These issues could improve
  106.    administration and topological flexibility of the IPng and solve the
  107.    flat problem of the IPv4.  The IPng routing protocols should include
  108.    policy-based features.  The IPv4 network topology is very complex and
  109.    it will continue to enlarge during the transition. It would be very
  110.    difficult or impossible to manage it without the "policy" tools.  The
  111.  
  112.  
  113.  
  114. Ghiselli, Salomoni & Vistoli                                    [Page 2]
  115.  
  116. RFC 1676             INFN Requirements for an IPng           August 1994
  117.  
  118.  
  119.    multicast capability as well as any other new features that fit in a
  120.    datagram network should be supported.  Regarding the Source Routing
  121.    feature, since we think that it deeply modifies the aim and the
  122.    "philosophy" of a connectionless network and it also introduces an
  123.    heavy complication in the end nodes and routers software, we don't
  124.    consider it a major issue.
  125.  
  126. 5. Layer 2 or communication infrastructure media support.
  127.  
  128.    This is an open field, rapidly changing, then it must be left open to
  129.    any evolution. What it should be recommended is to be compatible with
  130.    the above network layer.
  131.  
  132. 6. Transition and Deployment
  133.  
  134.    We faced the problem of the transition of the DECNET global network
  135.    to DECNET/OSI over CLNS. This activity is now proceeding to the last
  136.    step and based on this experience we would underline some points that
  137.    we found important during the transition deployment.  The transitions
  138.    must be planned and developed in a distributed way.  This means that
  139.    every organization should have the possibility to plan and start
  140.    their network migration without loosing connectivity with the
  141.    existing global internet.  Of course, the compatibility with the IPv4
  142.    world must be maintained, this mean that a new generation system must
  143.    interwork with both the IPv4 and IPng nodes, using the same
  144.    applications.
  145.  
  146.    However, it is important to define a deadline for the backward
  147.    compatibility in order to avoid huge software maintenance in the user
  148.    systems and a "multi-topology" management.  We think that a dual
  149.    stack approach could simplify very much the transition, whereas a
  150.    translation mechanism would need a widely and deep coordination in
  151.    order to maintain the global connectivity during the transition
  152.    period.  The dual stack is simpler and could be easily developed, but
  153.    it is important to push in order to have pure IPng with global
  154.    connectivity as soon as possible; this could happen when there are no
  155.    more "IPv4 only" hosts.
  156.  
  157.    Indeed, the drawback of the dual stack configuration is that you
  158.    continue to suffer for the IPv4 address space exhaustion and that you
  159.    must continue to support the IPv4 routing protocols and
  160.    infrastructure.  We don't think that the tunnel solution to
  161.    interconnect the IPv4 isle could give good performances to the users.
  162.    Then, it is important to maintain the IPv4 connectivity and the dual
  163.    stack software support in the End System software in a determined
  164.    timeframe, or the transition will never end.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Ghiselli, Salomoni & Vistoli                                    [Page 3]
  171.  
  172. RFC 1676             INFN Requirements for an IPng           August 1994
  173.  
  174.  
  175. Security Considerations
  176.  
  177.    Security issues are not discussed in this memo.
  178.  
  179. Authors' Addresses
  180.  
  181.    Davide Salomoni
  182.    INFN-CNAF
  183.    National Institute of Nuclear Physics - National Networking Center
  184.    V.le Ercolani, 8
  185.    40138 Bologna - Italy
  186.  
  187.    Phone:  +39 51 6098-260
  188.    Fax:    +39 51 6098 135
  189.    EMail: Salomoni@infn.it
  190.  
  191.  
  192.    Cristina Vistoli
  193.    INFN-CNAF
  194.    National Institute of Nuclear Physics - National Networking Center
  195.    V.le Ercolani, 8
  196.    40138 Bologna - Italy
  197.  
  198.    Phone:  +39 51 6098-260
  199.    Fax:    +39 51 6098 135
  200.    EMail: Vistoli@infn.it
  201.  
  202.  
  203.    Antonia Ghiselli
  204.    INFN-CNAF
  205.    National Institute of Nuclear Physics - National Networking Center
  206.    V.le Ercolani, 8
  207.    40138 Bologna - Italy
  208.  
  209.    Phone:  +39 51 6098-267
  210.    Fax:    +39 51 6098 135
  211.    EMail: Ghiselli@infn.it
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Ghiselli, Salomoni & Vistoli                                    [Page 4]
  227.  
  228.